Type Listの問題点
https://github.com/golang/go/issues/41716 このissueの議論が重要そう
Type Listの問題点、またはType Set proposalで改善するポイント
そもそも表現力が上がる(type listだけだと表現力が少ない)
There would be no way to permit the type int without also permitting all defined types whose underlying type is int.
型switch Type switch statementsの問題
埋め込みをしたときの挙動がわかりにくい
https://go2goplay.golang.org/p/G_0oGEOK5VP
https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-lists-in-embedded-constraints
nilとzero valueに関して
Regarding nil-ness of sum types: I find it strange that the proposed rules require type switaches to exhaustively cover the possible types in the sum or include a default case, but don't require covering the nil case.
https://github.com/golang/go/issues/41716#issuecomment-701949406
重要そうなコメント
https://github.com/golang/go/issues/41716#issuecomment-701996509 一番重要そう
type-listがbuilt-inを含むならexhausting requirementは意味がないという指摘
exhausting requirementがそもそも不自然で必要ない
type-list-interfaceでType assertionができるのか? できるとすれば動的型のunderlying typeを調べる必要があるがこれは難しい
提案: >Only generic type parameter constraints can use type-list interfaces that contain builtin types.
rogpeppeは "underlying type matching" に批判的
griesemerはこれを後から除くことはできないが後から足すことはできると指摘
一方で type Kelvin float32が比較できなかったら残念だよね
operator(T < T)のようにしたら?
griesemer: operatorだけが問題ではなく、1234が代入できるかどうかが判定できたりやconversion可能性を判定できる必要がある。だからtype listを考案した
https://github.com/golang/go/issues/41716#issuecomment-714416707
genericsが自動的にunderlying typesに働くことが困難の原因と述べている
Only generic type parameter constraints can use type-list interfaces that contain builtin types.
underlying typesの困難を避ける意味がある
ianlancetaylor
I think it's fine if we say "this proposal doesn't give us what we want for sum types, so let's not adopt it." But I would argue that if we say "let's adopt this proposal but make interfaces-with-type-lists behave differently when used as type constraints and when used as ordinary types," then this proposal is no longer providing a benefit that is worth the cost. Better than that would be to adopt a different version of sum types that is not easily confused with type constraints. (Or, of course, not adopt sum types at all.)
良い質問 https://github.com/golang/go/issues/41716#issuecomment-702286896
https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-lists-in-embedded-constraints
この辺をクリアにするにはType setの概念が有用そう
If all of the types in the sum type S are defined (not underlying) types, and all of those types implement the methods of an ordinary interface type I, should a variable of type S be assignable to I?
これはNoらしい
型switchに関して
もともとdefaultがあるか全ての型がcaseに含まれることを要求していたが取り消された
typelistに型を加えたらそのinterfaceに依存するコードが壊れるのか?
underlying typeが一致する場合はマッチするのか不明瞭
code: 1.go
type A int
type X interface {
type A, int
}
func main() {
var x X = A(0)
switch x.(type) {
case int: // matches, underlying type is int? NO.
case A: // matches, type is A
}
}